** Why are these changes being introduced:

After watching our search traffic for a few months, we have seen some
terms come in that are clearly related:

* 'Scientific American'
* 'scientific american'
* '"Scientific american"'

While there are valid reasons to store the term exactly as the user has
submitted it - there are also good reasons to standardize these values,
to look for clusters and related terms.

** Relevant ticket(s):

n/a

** How does this address that need:

This defines a TermFingerprint model, which is related to the Term model
via a belongs_to relationship (a Term belongs to its TermFingerprint,
and a TermFingerprint can have many Terms). The migration to define this
model includes a migration to populate records for Terms we've already
received.

The Term model gets two lifecycle hooks, one to add new fingerprints for
every term, and another to delete a TermFingerprint if no remaining
Terms reference it.

Beyond the methods needed to handle these creations and deletions in as
seemless a way as possible, we also add a .cluster method to the Term
model, which will return an array of all related Terms (but not the Term
itself - so a Term that has a unique fingerprint will return an empty
array). This method will be used as part of a future inspection UI.

Building the models in this way will also allow for querying based on
shared fingerprints - for example by adding a :has_many_terms scope
on the TermFingerprint model.

** Document any side effects to this change:

Two things:

1. A quirk of this implementation is that it is possible to delete a
TermFingerprint record, which does not delete the related Terms (and
thus also SearchEvents, Detections, and Categorizations). The Term will
then have a null fingerprint. The next time the Term is saved, its
fingerprint will be regenerated. No other operation should be impacted
by this arrangement.

For the life of me I can't anticipate why we might delete a fingerprint
- but the relationship needs to be optional to avoid further pain when
working in the console.

2. The process for calculating this TermFingerprint value is similar -
but not identical - to that for handling the SuggestedResource records.
The difference is that the TermFingerprint method removes """
sequences - which might need to be added to SuggestedResource. Both
methods should probably be abstracted out to a shared helper method,
honestly.

I noticed this when running make lint - not sure how it slipped
past my notice when working on the confirmation work.

Rename migration to get date sort correct

Run migrations

** Why are these changes being introduced:

It makes sense that the Fingerprint model is where the logic to
calculate a fingerprint value is maintained, and not in the Term model.

** Relevant ticket(s):

code review

** How does this address that need:

This moves the fingerprint logic from the Term to Fingerprint model.
Because of this, the Term model changes to use its new location (from
inside the lifecycle hook where the Fingerprint record gets created).

We use an instance method for this, because at the time of use there is
not yet a Fingerprint record that could call the method internally.

We also copy-paste the tests for this method from the SuggestedResource
implementation (which should be removed in a future PR).

** Document any side effects to this change:

I can think of two possible side effects:
1. the SuggestedResource implementation of the fingerprint is now very
much duplicative, and should be removed (coming in a future ticket)

2. It is a bit awkward to rely on an instance method for calculating
the fingerprint value. In an ideal case, register_fingerprint would
use something like:

self.fingerprint = Fingerprint.find_or_create_by(phrase)

... and then the Fingerprint model would:
a. receive the phrase argument
b. calculate the fingerprint for this phrase
c. look up to see if such a record exists already, and return it
d. create the record if none exists, and return _that_

A custom initialize method feels like it would work for this, but I
think that's considered an antipattern in Rails?

For now, I think this works.

This comments out the initial calculation of Fingerprint records from
the migrations in this PR. A following commit will add a rake task that
will focus on this work.

A side effect of this work is that we need to change the fixtures used
for our test suite, to match the state the migrations will produce. This
in turn causes some tests to change, because some tests will require
additional setup work.

More complex tests now have code comments to indicate this sort of
sequencing.

Includes a very rudimentary test, and finally removing the (commented out) block from the db migration.

Three tests need to be updated to account for the different starting
position.

Until now, we've been building the Fingerprint model to include a field
also named "fingerprint" for the actual string value of the fingerprint.
This removes that duplication by changing the field name to be "value".

As a result of updating the migration with this new terminology, we also
update the alias / delegation up to the Term model, so terms can still
find the string via the term.fingerprint_value attribute.

The fixtures use the updated field name, and some references to the new
field name (in application code and in tests) are updated.